In conventional networked systems, data is often transmitted between digital devices over a variety of protocols. Switching platforms exist that are capable of converting and switching data from one protocol to another. For instance, data can be transmitted by an IBM mainframe over an ESCON channel protocol. A switching platform can receive such an ESCON data stream and redirect the data over a different bus protocol like SCSI, or even a network media such as ATM. Using such devices, IBM mainframes can communicate to otherwise incompatible devices such as a SCSI storage device using a known protocol like ESCON.
Switching platforms may also allow remote access to devices that are physically located beyond the limits of a particular communications media. For instance, local fibre channel data streams can be converted to a wide area network such as SONET and then be transmitted across the continent. A separate switching platform at the receiving site can receive the network protocol data stream and convert it back to the original channel protocol or even another protocol altogether, whatever is appropriate for the receiving device.
As is well known, it is important that any data corruption along a transmission path be identified and corrected. Standard techniques for detecting data corruption include parity checks and CRCs (or cyclic redundancy checks). Parity checks require that an additional bit be added onto each byte of transmitted data. The additional bit is selected so that the entire byte contains either an odd number of ‘one’ bits (odd parity) or an even number of ‘one’ bits (even parity). Unfortunately, this error detection scheme does not check errors that create an even number of bit errors within a single byte.
The CRC technique is an improvement over simpler methods of error detection. In standard techniques, a CRC value is appended onto a grouping of data during data transmission. When the data is received, a new CRC value is calculated and compared with the original value. If the values do not match, there has been a transmission error. Alternatively, the data and the appended CRC value are combined to calculate a CRC value, which can then be compared with a constant to determine if there were any errors during transmission.
While various channel and networking protocols check for point-to-point data transmission problems using parity checking and CRC values, these end-to-end techniques are not useful in discovering data transmission problems within the switching platform domain. In other words, if transmission errors arise in the transmission from one switching platform to another, it would be inefficient to require the destination (i.e., the remote storage device) to discover the transmission problem and then request a retransmission from the source (i.e., the computer).
What is needed is a technique to calculate and check CRC values in a switching platform domain beyond that provided by the basic point-to-point protocols used by the attached devices. Specifically, what is needed is a method and device that snoops the hardware used for normal fibre channel communications to create a sequence-level CRC generator and checker.
At the same time, some fibre channel protocols such as FC-BB, FC-BB2, and FC-IP do not utilize sequences, and instead transmit data only in single fibre channel frames. When transmitting these protocols, there is no need for the switching platform domain to create a sequence level CRC value, since there are no sequences and each individual frame contains its own CRC value. This value is not recalculated within the switching domain because these fibre channel protocols require that intermediate switches existing between the originator and responder pass the frame-level CRC values unaltered. Thus, it is necessary for the method and device that generates a sequence-level CRC value for multiple-frame sequences to also allow single fibre channel frame communications of these protocols to pass through the switching domain with their frame-level CRC values unaltered.